1. Field of the Invention
The present invention generally relates to computer bus architectures and methods for transference of data, and, in particular, relates to bus bridge architectures for connecting two or more buses and for handling interrupt requests from a device on a subordinate bus to the central processing unit via the bus bridge device.
2. Description of the Prior Art
The disclosure herein utilizes Peripheral Component Interconnect (PCI) architecture for illustration purposes where the present invention and the embodiments thereof are not limited to this particular bus architecture. The PCI bus is a high performance 32-bit or 64-bit bus with multiplexed address and data lines. It is intended for use as an interconnect mechanism between highly integrated peripheral controller components, peripheral add-in boards, and processor/memory systems, providing high bandwidth throughput demanded by modern graphics-oriented operating systems such as Windows and OS/2. It is typically found in (but not limited to) IBM compatible personal computer systems. The specifications for the PCI bus standard is provided in the following documents and are incorporated herein by reference: PCI Local Bus Specification, revision 2.1; PCI-to-PCI Bridge Specification, revision 1.0; PCI System Design Guide, revision 1.0; and PCI BIOS Specification, revision 2.1. These documents are available from a consortium of industry partners known as the PCI Special Interest Group (SIG) and are collectively referred to as the PCI Specifications in this disclosure.
FIG. 1 shows one implementation of a PCI bus architecture. Here, the central processing unit (CPU) 10 is connected to a Host/PCI cache bridge 12 via a CPU local bus 14. The Host bridge 12 serves as a bridge to other buses, including a memory bus 16 connected to main memory 18 and a PCI bus 20. Via the Host bridge 12 and the PCI bus 20, the CPU is able to communicate with a number of peripheral devices, including an audio device 22, a motion video device 24 and its video memory 26, a SCSI host bus adapter 28 connecting several other SCSI devices, a LAN adapter 30, and a graphics adapter 32 and its video frame buffer 34. The PCI bus 20 can also communicate with other bus types through the use of a bus-specific bridge 36 and the corresponding bus 38.
Typical PCI bus implementations will support up to four add-in board connectors on the motherboard where the connectors are Micro Channel (MC)-style connectors. PCI expansion cards are designed with an edge connector insertable into the add-in board connectors on a motherboard.
However, a system incorporating a single bus has some limitations. For example, a bus can only support a limited number of expansion connectors due to the fact that a bus will not function properly when there are too many electrical loads (i.e. devices) placed on it. Moreover, the devices that populate a particular bus may not be able to co-exist in an efficient manner in a set-up where all the devices demand high levels of bus time--causing an overall degradation in the performance of the system.
These problems can be solved by adding one or more additional PCI buses into the stem and re-distributing the device population. The PCI Specifications provides the definition a PCI-to-PCI bridge device. This device can either be embedded as an integrated circuit on a bus or may be in the form of an add-in card that is pluggable in a PCI expansion connector. The PCI-to-PCI bridge provides a bridge from one PCI bus to another PCI bus, and it causes one electrical load on its host PCI bus. The new PCI bus can then support a number of additional PCI compatible devices and/or PCI expansion connectors. The electrical loading constraint is therefore solved because the loading constraint is on a per bus basis, not on a system basis. Of course, the power supply in the host system must be capable of supplying sufficient power for the load imposed by the additional devices residing on the new bus(es).
The PCI bridge provides a low latency path through which the processor may access PCI devices mapped anywhere in the memory space or the I/O address spaces. It also provides a high bandwidth path allowing PCI masters direct access to the main memory. The bridge may optionally include such functions as data buffering/posting and PCI central functions (e.g. arbitration). Terminology wise, the PCI bus closest to the host processor is referred to as the primary bus, and the PCI bus that resides behind a PCI-to-PCI bridge is referred to as a subordinate bus where the subordinate bus farthest from the host processor is called the secondary bus.
FIG. 2 illustrates an implementation of a PCI bus system with two PCI-to-PCI bridges connecting to two levels of PCI buses. Here, the CPU 50 is directly connected to the host bus 52. The system memory 54 is connected to the host bus 52 via system memory controller 56. A host-to-PCI bridge 58 establishes a connection between a host bus 52 and a downstream subordinate PCI bus 60 where two PCI devices 62 are connected to it. The subordinate PCI bus 60 further connects to another downstream PCI bus 64 via another PCI-to-PCI bridge 66. PCI bus 64, being the furthest from the host bus, is referred to as the secondary bus and is connected to two PCI devices 68. By using PCI-to-PCI bridges to connect to other PCI buses, architectures overcoming the problem of bus overloading and permitting the expansion of buses are created.
The PCI-to-PCI bridge functions as a traffic coordinator between two PCI buses. The bridge does not initiate a transaction on either PCI bus on its own. Its job is to monitor each transaction that is initiated on the two PCI buses and to decide whether or not to pass the transaction through to the opposite PCI bus. When the bridge determines that a transaction on one bus needs to be passed to the other bus the bridge must act as the target of the transaction on the originating bus and as the initiator of the new transaction on the destination bus. The fact that the bridge resides between the transaction initiator and the target is invisible to the initiator as well as to the target. In addition to determining if a transaction initiated on one bus must be passed through to the other, the bridge also supports additional functions as specified by the PCI Specifications. A bridge may also incorporate a set of device-specific, memory-mapped or IO-mapped registers that control its own functionality. In this case, it must recognize and permit accesses to these registers.
Referring to FIG. 3, the bridge 70 connecting two buses, the primary bus 72 and the secondary bus 74, stores the transactions initiated by devices #1, #2, and #3 (76, 78, 80) in a storage area referred to as data FIFO 82 and passes these transactions one at a time on to the primary bus 72. In handling interrupt requests, each device is assigned with a device number and when a device initiates an interrupt request, the request is passed to the bridge device 70 via a respective interrupt line, 86, 88, or 90. Here, the interrupt lines may be logical lines rather than physical lines. Once the bridge device 70 receives an interrupt request, the request is passed straight through to the primary bus 72 via another interrupt line 84.
When the CPU receives the interrupt request, the CPU, having the ability to arbitrate bus usage, holds all transactions from all devices in order to service this request. To service this request from a device on a subordinate bus, the CPU generally would allow all transactions in the bridge data FIFO to complete or would flush the content of the bridge data FIFO. Then, the CPU services the interrupt request accordingly. When the task for the interrupt is completed, normal operation is resumed.
Under this method, there is a great deal of inefficiency in the utilization of CPU cycle time. In the case where all of the transactions in the bridge's data FIFO is flushed, all the transactions initiated by the devices on the secondary bus would have to be re-initiated, resulting in a waste of cycle time. Even in the case where the transactions stored in the bridge's data FIFO are allowed to complete, all other devices would have to wait for the interrupt to clear before normal operation can resume, again causing delay and wasting cycle time.
Therefore it would be desirable to have a method and apparatus for processing interrupt requests from devices on a subordinate bus that can efficiently utilize cycle time and causes minimal delay in processing the transactions from all devices.